September 20, 2005 

Dana Devoe/Tim Jowers 
Inventors 

14781 Memorial Dr ^ 
Houston, TX 77079 



United States of America 
Patent and Trademark Office 

Dear Debra F. Charles, 

This is a "request for reconsideration or further examination of the 

claim" • Please consider this further clarification of patent 09/759, 723 , Method 
of reducing fraud in credit card and other E-business. This 
explanation is submitted as soon as possible whereas the inventor did not 
receive the communication on the status about this patent despite calling the 
USPTO once each six months for the past several years and providing updated 
contact information for the inventor. As well, I called in January, March, May, and 
June of this year about this patent and was always told it had no status update 
and then it was being reviewed after about four and Vz years. 

I had no contact with the original filing attorney due to relocations to other cities 
and jobs over that time period. Please update all records to reflect my information 
and, additionally, timjowers@qmail.com and 803-740-9820. Please let me know 
of a particular form I must file for this as I have been told to file a "Change of 
Address Correspondence" but will consult the attorney who assisted us in the 
original application. 

Please correspond with me too keep me informed of the status as possible and 
with the other inventor, Dana DeVoe who is contactable at 
danadevoe@vahoo.com or by phone at 1-904-305-0131 . 

Please review the following justifications for our patent and let us know what 
else we need to do to proceed. 

Thank you, 
Tim Jowers 



Patent Application Number: 




Justification and Rebuttal Responses for Claim Objections 



summary: A series of Objections were raised in the Office communication about 
our patent application. We have analyzed each reference for relation to our 
patent and have found each to be distinct from our patent. We have provided 
fairly detailed explanations of how our invention is different and independent of 
those referenced. As well we have accepted the claims of triviality with some 
insult and are quick to point out these claims are self refuting as related patents 
are quoted in the Objections and are themselves justification of the non-triviality 
and non-obvious nature of work in this area. The granting of these is a rebuttal 
for general claims of triviality and of obviousness but more exact rebuttals and 
justifications are given below. The rebuttals and justifications are grouped by 
Objection number. 

Objections : 

1. Improper number. 

No Rebuttal . We paid a professional and experienced patent attorney but 
this mistake still occurred. We did not know to change this point when we 
reviewed the patent application before submission but will correct this on any 
future filings. 

2. Claim 8 rejection. 

Again, erroneous filing. Sorry about that. 

3. "Claims 1-12 are rejected under 35 U.S.C. 101 because the bodies 
of the claims do not reject technology, i.e. computer 
implementation or any other technology in a non-trivial manner." 

Rebuttal i : This technology cannot be called trivial when there is other 
technology of a similar nature which is patented, so similar that below are listed 
several area that are believed to be identical to others. 

Rebuttal 2 . The patent application fully defines a technology and the 
technology is a computer software system. The very technique for integrating the 
system is nontrivial as is the required program flow as defined in the patent 
application. Figure 1 documents a collaboration diagram and such diagrams are 
the industry standard way to document software design. Figure 2 documents a 
flowchart and prior to the popularity of the Unified Modeling Language flowcharts 
were the de facto standard for documenting software design. Figures 3a, 3b, 3c, 
and 3d document a user interface design for explanation of the process of the 
invention. 

3.1 The claimed invention must produce a "useful, concrete, 
tangible result" . 

Rebuttal i : Our system expressly produces a binary result: reject or 
approve. This is stated in the patent application. 



Rebuttal i : Our system expressly produces a binary result: reject or 
approve. This is stated in the patent application. 

Rebuttal 2 : The system also produces system data used between 
modules which is useful and concrete which is the user's profile settings. These 
are stated in the application and shown in the diagrams. For example, 1.1 . shows 
the data for the usage line must be configured by the user so this data is passed 
by the user interface. For example, 7.2 shows this data must be accessed by the 
issuing bank so this data is accessible by the bank in an automated function. For 
example, 8.1b shows the usage line data must be accessed during the 
authorization transaction. In all instances, the data accessed is concrete data 
representing the usage line for the account holder's account. 

3.2 The claimed invention must use technology in a non-trivial 
manner . 

Rebuttal 1 : This technology cannot be called trivial when there is 
other technology of a similar nature which is patented, so similar that 
below are listed several area that are believed to be identical to others. 

Rebuttal 2 : The system is nontrivial. This system has not been fully 
invented or implemented by any other party due to its innovativeness 
and complexity. As an experienced software consultant I propose that 
very few software engineers even have the expertise to design this 
system properly. This is a key reason some 80% of software projects 
fail. It is our experience and insight which has made this system 
possible. Software design and implementation is absolutely in no way a 
trivial endeavor. 

Rebuttal 3 : The system is nontrivial. The patent application documents using 
inline computer and human processes for authentication and validation and this 
is not only not done by others but also very difficult to conceive and create . The 
inline processes include real-time (what the industry calls "real-time" but is really 
"inline) contact with the account holder to validate the transaction. This is very 
non-trivial: the closest any other company has come is just this year Discover will 
email users of a credit card transaction ex post facto if it is past a certain limit. 
Our patent documents how email or other communication can be inserted into 
the credit card process DURING THE TRANSACTION. Also, Verified by Visa is 
simply another password which must be supplied during the authentication and, 
in fact, is possibly trivially different than D'Agostino but is very far short of our 
invention. Our invention provides a solid computer software design to greatly 
reduce fraud and control spending. 

The invention of the body of the claim must recite 
technology. If the invention in the body of the claim is 
not tied to technological art, environment, or machine, the 
claim is not statutory. 



Justification 1 : The patent application itself is a complete 
software specification. The specification is complete enough to generate the 
skeleton classes and methods. In fact, modern tools such as Rational Rose can 
automatically generate the classes and methods from a diagram such as a class 
diagram which is embodied within a collaboration diagram. This is a complete 
technology. Software specifications and software diagramming are used every 
day in almost all software development companies in order to explicitly document 
software design. In fact, the standard of quality, Software Engineering Institute's 
Capability and Maturity Model requires software design documentation for any 
acceptable level of quality (levels above 1, the lowest level). 

Justification 2 : The patent application is tied to the art of data 
processing and specifically processing credit authorizations. The claim is 
expressly tied to credit authorization systems. The claim is not tied to a specific 
machine although the software may be deployed in a hosted environment or on 
the machines at the customer bank. 

Justification 3 : The patent application is tied credit authorization 
and must exist in this environment. The patent application is tied to the Internet 
or other communications mechanisms for the part which communicates with 
humans. 

3.3 Obvious to a person with ordinary skill 

Rebuttal 1 While the technology and the approach seem similar 
the major different between our approach and the others listed in your 
rejections is as follows: Bank side processing and user side 
processing. Through the use of the internet, a card holder is able to 
change the parameters of approval used by his banking institution. The 
parameters we call usage line. This approach is different than all of 
the other patents as the bank authorization cannot be modified by the 
user of the card. The bank sets the parameter for approval the card 
user is unable to change them in all other systems. 

Prior art from Adams and D'Agostino for claims 1,3,4 and 12. 

Rebuttal i : Neither Adams nor D'Agostino have patented our process or 
other aspects of our invention. D'Agostino's is the most related as it is related 
in the definition of categories. 

Similarities and Differences from Adams: 

Adams basically patented keeping a list of bad card numbers in a computer 
rather than on paper and setting a lower total credit sales limit above which 
transactions must be pre-authorized. In the 1980's vendors had to lookup on 
paper to verify each credit card presented was not on a blocked list. Adams 
patented automating this lookup. 



In contrast to the Objection claim that Adams table of decision rules may 
be imagined to cover our usage line please observe that Adams makes 
absolutely no mention of any validation besides checking the credit limit, the 
limit on total unauthorized credit issued at a merchant, and the list of bad 
cards. At the time of Adams' patent application many merchants did not 
submit credit card purchases in real-time but, rather, waited to batch the 
submission at night. Adams' patent in reality does not intersect our patent 
application and is only related in that it relates to credit cards. Furthermore, 
"rules" are by definition open-ended logic and the use a "rules engine" in no 
way defines the behavior of a system. Depicting a table of rules (which is in 
fact not even a Rules Engine by any stretch of the imagination) shows nothing 
about the actual behavior of the system other than some program logic will be 
used. It in no way specifies what the program logic is. Imagine if Adams 
would have meant calling a cell phone to approve a transaction by his rules 
table? Certainly not as cell phones were not even prevalent when he filed the 
patent application. His authorization is only by the merchant's credit machine 
and not even the user , and his "rules table" is a software design 
documentation that he will reference a table in computer memory or from disk 
to list bad credit cards and a limit to the amount of credit to authorize without 
communicating with a central processor. 

The flowchart labeled Figure 2 in Adams documents the de facto process 
for credit card authorizations. Almost every single transaction which occurs 
today uses a credit limit check as labeled in steps 52, 54, and 56 in the 
flowchart. 

Adams cites the use of a "central processor" while the Visian systems 
requires no centralized system. As stated in paragraph 5 Adams explicitly is 
speaking about automating processes with the term "online" and not at all 
speaking of using the Internet or data gathered from the Internet; after all, the 
patent was filed in 1990 before the Internet exploded . Circa 1990 the term 
"online" was synonymous with "automated" not with "the Internet". 

A key phrase in Adams reflects how dissimilar Adams patent is to our 
application, "However, for low value transactions, the losses tend to be lower 
and the benefits gained from on-line authorization do not justify the added 
costs and delays involved in obtained [sic] an no-line approval". The essential 
similarity is both patents cover transactional approval but the pivotal 
difference is Adams speaks of a very limited system maintained by a central 
processor while our patent covers a system controlled by the end holder of 
the credit account and managed by him or her. Another, even more essential 
point, is Adams covers authorization only by credit limit and card validity: 
these are de facto practices and are not something we have attempted to 
patent. 

In fact, Adams only covers authorizing transactions above a certain limit 
and does not cover authorizing all transactions. Furthermore, Adams 
transaction limits are set by the terminal owner or central processor and not 
even the bank or even the customer as in our invention. 



Similarities and Differences from D'Agostino: 



D'Agostino presents a neat idea whereby the customer receives a 
transaction code which may only be used for a certain purpose at a certain 
merchant. This idea is quite different from our patent application but is very 
similar to existing single use discount coupons issued by Lowe's and other 
merchants and may be seen as similar to one-time use credit cards. In 
D'Agostino's invention the customer does not reveal a credit card number and 
the merchant must be able to process a "transaction code" whereas in our 
invention the merchant does not have to change current business practices . 
This is so important it bears repeating because the reason fraud has not been 
successfully combatted is most approaches require a merchant to accept 
non-standard cards/credit authorizations and/or purchase expensive 
additional equipment while our invention does not change the common 
processes of the merchant. Our market analysis revealed the only way to 
widely disseminate a fraud reduction technology was to make the barrier for 
entry almost nothing for the merchants and this is why our design is the way 
we did it rather than as an additional cost to the merchant such as 
D'Agostino's design . 

The "payment categories" (Section 3, line 2) written in D'Agostino is 
"promotional information" (section 2 line 12) such as advertisements and in 
no way the same as the usage lines configuration described in our invention. 
In fact the authorization process described in D'Agostino ( Section 3, lines 20 
and 21) is a credit check whereas in our invention the usage line is an 
essential part of the authorization process. D'Agostino does attempt to patent 
using a dollar amount limit set by the customer or authorizing system but such 
credit limits are commonplace and have been for many years and this is not a 
refuting or redundant facet of either invention as it is not patentable as it 
exists already. 

D'Agostino does have limits on time, amount, and merchants but these are 
inherently tied to a transaction code as thus unable to be applied to a normal 
credit card . While the authorization process is different in D'Agostino's 
invention and ours, D'Agostino's payment categories are a subset of our 
categories and, importantly, limited to amount, time, and merchants who are 
participating in his system while ours includes time and amount as well as all 
merchants who accept credit cards and, more importantly, include a vast 
usage line which is customizable by the user on the Internet and includes 
many other points for authorizing or rejecting the transaction. 

claim i : Adams does not cover a usage line . As described above 
D'Agostino does cover categories but his criteria are a subset of ours and the 
authorization process is drastically different 

claim 3 : Adams lists pre-authorized transactions but only in the context of 
credit limits and valid credit cards. D'Agostino does not use a normal credit 
card and requires a special transaction code which is taken as valid by the 
system while our invention uses a normal credit card and checks validity 
dynamically using a set of rules configured by the user and the authorizing 



company. Furthermore, neither cited system includes that a pending request 
for payment could require approval from the user and the bank in realtime as 
we document . 

claim 4 : Adams does not include a usage line or real-time communications. 
As described above D'Agostino does include some basic category criteria but 
does not include realtime communication with the user . 

claim 12: Claim 12 is for use by business representatives and this 
assignment of use is not covered at all in Adams or D'Agostino . A usage line 
is not described in Adams. No restriction based on business representatives 
(human, electronic, or otherwise) is made in D'Agostino either. 

4. Prior art from Adams, D'Agostino, Brake, and Bragg for claims 
2,5,6,7,8,9,10, and 11. 

As shown above, Adams does not define any patentable part of our 
invention. 

As shown above, D'Agostino only covers limits based on amount, time, and 
merchants and otherwise does not define any patentable part of our 
invention. D'Agostino's categories are a restricted subset of our usage line 
and even restricted in how we defined schedule, time, merchants, amounts, 
and amount aggregation. 

Brake, Jr. has patented a card which may be signed up as a credit card or as 
a transaction card such as a gas card. The card then becomes a credit 
vehicle but does not necessarily act as a general credit card which may be 
used by any vendor who accepts credit cards. Brake Jr. also speaks at length 
about reward points which were in common use already at the time his patent 
was filed . Brake, Jr. also covers issuing a card to a customer with only a 
phone call needed for activation; yet, while he claims only two steps are 
needed, in fact, his flowchart 3C shows no less than seven steps are needed 
in his process; yet, regardless, we have not attempted to patent a signup 
feature, reward points, or a method reguiring vendors sign up to receive a 
credit vehicle . One of the essential points of our invention is it does not 
require vendors to change their daily operation or to buy additional 
equipment . While Brake, Jr. makes frequent reference to features" the only 
feature appears to be the ability to sign up for the credit card and the ability to 
gain reward points. Brake never elaborates on how his credit card will be able 
to be used as a gas card or restricted to one specific vendor . The normal way 
to do this outside of our invention is to have a credit vehicle accepted by a 
chain of stores and processed independently of normal credit card 
transactions. We have made no attempt to patent gasoline cards, telephone 
calling cards, or chain-store credit cards . Considering all of Brake. Jr. none of 
his patent overlaps any of the claims of our patent. 



Brake, Jr.'s process is for signing up for a credit card and not for inline 
authorization. Brake, Jr.'s process is very different from ours in the steps and 
the sets of technologies with the main similarity being he uses the Internet for 
signup while the Internet is just one of the forms of communications used in 
our invention. 

Blagg documents allowing the credit limit and the authorized user of a credit 
card to be set. These are already pre-existing usage parameters of all credit 
cards (except so-called "unlimited" cards) and allowing these to be set is not 
a novel idea. Blagg has received a patent for the process by which these 
may be set - particularly the use of an account group rather than a specific 
person as an account holder. Blaqq's patent covers grouping and linking of 
credit card accounts and sending a single statement for the grouped cards: 
neither of which are covered by our patent application . 

Blagg's patent does cover restricting a credit card's usage by geographical 
region. Importantly, Blagg submitted a process for configuring card accounts 
via the Internet but makes no mention of real-time, inline authorization using 
the Internet, cell phone, or other means which is an essential claim in our 
application (Claim 11 for instance). 

I note in Blagg's repetitive listing of financial limits that no mention of 
statistical, averaging, or percent-wise limits is made. A typical magnitude 
limiting and measuring function for anything which has a numerical value 
would be to set a limit by a rolling average for the measured item (in this case 
an account), to set a limit based on statistical averaging based on season, 
grouping of people, or other measurement grouping, or to set a limit based on 
the percent of the total amount available (in this case the total credit 
available). Note that the total credit may span multiple accounts and even 
account for bank accounts and other personal assets as allowed and 
specified by the account manager and/or owner. 

Blagg's patent is overlaps ours in the usage of geographical constraints on 
authorization though thus is only one of our many constraints. As the usage of 
geographical constraints is not an explicit claim in our patent then this should 
be no problem. 



Thank you for taking the time to review our responses to 
your Objections. We believe we have provided a compelling 
argument for the granting of a patent on our invention. We 
are excited about the opportunities to reduce credit card 
fraud and anticipate ever more advances in this technology 
arena . 

Please communicate with us openly about any further efforts 
we need to take to further this patent process. 

Sincerely, 

Tim Jowers, TimJowersS yahoo. Com 
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In the case of Michael Daly his approach works by communicating with each vendor new 
maximum purchase limits, however in our approach, the bank stores the limits for the 
usage of the card purchases. Also the user can change those parameters such as purchase 
amount and several other parameters all over the internet, however Daly does not indicate 
how the redefine limits would set. 



While the technology and the approach seem similar the major different 
between our approach and the others listed in your reject is as 
follows: Bank side processing and user side processing. Through the 
use of the internet, a card holder is able to change the parameters of 



approval used by his banking institution. The parameters we call usage 
line. Then bank use them to determine if a transaction should approved 
or not. However it is the user who sets these values and these values 
can be set at any time by the user. 



